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As those of you that come to the meetings have already 
discovered, there was no July issue of Fuji Facts. Lack of 
submissions and editorial time conspired to produce this 
result. Those of you that do not come to the meetings have 
just discovered that ACEC no longer mails Fuji Facts on a 
monthly basis (although this service is still available for a 
$3.00 yearly fee); newsletters not picked up at our meetings 
will be saved, and mailed three times a year (April, August 
and December). 

The major theme for this month is file "compaction" 
programs. Anyone with a modem has surely come across one 
or more of these. In short, these programs' purpose is to take 
one or more files and combine them into a smaller "pack- 
age". This not only decreases the amount of disk space 
necessary to store them, but lessens the time required to 
download them from bulletin board systems as well. Al- 
though having choices is usually a desirable state, the dif- 
ferent file compaction programs which currently exist for 
the Atari computers are mostly a source of confusion. The 
feature articles in this issue will hopefully clear up some of 
this confusion. 

I've also continued the series on SpartaDOS for begin- 
ners; I hope to follow up on this with a more detailed set of 
tutorial articles from the ACEC BBS. 



In the "humor" department, I've reprinted D.F. Neffs 
fantastic piece on the new ST-emulator for the eight-bit 
Atari computers — I thought that this was probably the single 
best computer-related article I've read all year! 

Then comes the "Review Department". With all the dis- 
cussions I've heard about The NewsRoom and The News 
Station, I thought a review of these programs would be in 
order. Who'd like to do the review of The News Station (and 
the Companion?) for next month? 

Several very good public-domain terminal programs are 
out for the eight-bit Ataris and a number of different 
modems. The three most popular are reviewed and com- 
pared for us by J. McCormick. Finally, the long awaited 
Atari XF-551 disk drive is subjected to yet another discus- 
sion (this one quite well written and informative). 

Also, please remember that nominations for the ACEC 
elections are coming up in just another month (also refer to 
the announcement on the back cover). It's time to think 
about returning some of what ACEC has given you — run for 
office! I know you get tired of hearing the same thing over 
and over, but it's true; being an ACEC officer really isn't very 
hard, and it's fun! 



A Review of File Compaction Systems^ 
A Second Look 

© 1988 by Marty Albert 



This article may be freely reprinted so long as this notice 
remains intact and the document is unchanged. 

Well, today, in GEnie Mail, I had a note that was sent to 
me by Jeff Kyle for Bob Puff, the author of Disk-Comm for 
the Atari eight-bit computers. The basic gist of Bob's letter 
and the note that Jeff sent along was that the reasons that I 
had trouble with Disk-Comm is that SpartaDOS "has too 
many bugs for me". 

Since I don't want to get into a DOS "war", nor is that the 
reason for these comparisons, I decided that I would repeat 
the tests with a more "standard" DOS, namely Atari DOS 
2.5. 
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The system used is a 256K 800XL with a single Atari 1050 
drive with US Doubler chips. I used the standard 130XE 
RAMDisk set as D8: for a 499 sector RAM drive. 

The programs tested were SHRINK XE version 1.00, 
SCRUNCH 2 version 2.0, Disk-Comm 3.2, and ARC/ 
ARCX version 1.2. 

Since I used Atari DOS 2.5, bytes mean nothing. All the 
file sizes are in terms of single density sectors. The files used 
for testing were as follows: 



Binary load file 


65 sectors 


SAVEd BASIC file 


64 sectors 


Daisy-Dot *.NLQ file 


15 sectors 


Atari font file 


09 sectors 


Text file 


60 sectors 


RLE picture file 


48 sectors 


Koala picture file 


27 sectors 


AMS song file 


52 sectors 


TOTAL SECTORS = 


340 



Note also that the % saved is in terms of the sectors used, 
which will of course be the same as the reduction in 
XModem blocks needed to transmit the file. 

The following table is a summary of the test results. 



oroaram 


time ere 


time rec. 


size 


% chanae 


SHRINK XE 


1:25 


0:50 


331 


-2.72% 


SCRUNCH 2 


4:30 


5:36 


325 


-4.62% 


DISK COMM 


4:08 


1:34 


326 


-4.29% 


ARC/ARCX 


5:20 


6:04 


249 


-36.55% 



So, there is the data. Now, for a few observations made 
while the test was going on.... 



SHRINK XE 

This is a nice little program. I like it, as I have liked all the 
past versions of SHRINK. It's fast, in fact, much faster than 
anything else in the test. It's easy to use with a nice menu. It 
allows the verification of files without actually needing to 
recover them. All in all, SHRINK XE is a good option to 
use. The only problem that I see is that it does very little com- 
paction. I guess you can't have everything, but I sure want it! 

SC R U N CH 2 

This is another good program, but it is a bit slow. In fact, 
SCRUNCH was not all that much faster than ARC, espe- 
cially when you look at the compaction difference. 

But, SCRUNCH does seem to work flawlessly in opera- 
tion. 

DISK-COMM 

Here we go again. No matter what I say, I'll get nailed for 
it. But, that's life! Disk-Comm is good. It's faster than ARC, 
but slower than Shrink. It compacts better than Shrink, but 
no where near what ARC does. On this test, I had none of 



the problems loading Disk-Comm that I did in the last test. 
First try I made, it ran like a champ. Bob also hinted at the 
idea that my copy of Disk-Comm was damaged because I 
had gotten it in ARC format. 

Well, the copy that I used for this test is the same copy as 
for the previous test. Sort of rules that out. Now, on to what 
I really like about Disk-Comm... The menu and use has to 
be one of the best and most user-friendly that I have ever 
seen, and I've been in this field for over 25 years now. It is, 
simply put, fantastic! Bob Puff has put a lot thought and 
energy and time into the design. It would be very easy to use 
with no documentation at all. 

ARC/ARCX 

OK, here it is again. ARC is the slowest, but it also is the 
one that does the most compaction. The fact that CRC er- 
rors happen is real. Jeff, in his note, stated that the CRC er- 
rors do not happen because of XModem padding and that 
the file is, "..damaged in some way. It may not be easily 
noticeable, but it's there." While that is, in strict terms, true, 
it still doesn't matter. If a text file has 10 characters on the 
end that are XModem padding, and the ARC/ARCX 
process changes one of them, the file has indeed been 
damaged. But, so what? Does it harm the way the file works? 
No. So long as a file is not operationally changed, who cares? 
Not me. Especially if I'm saving 35% of the time/money 
needed to download the file. 

IN CONCLUSION 

So, it looks like the data is really unchanged, except that 
we now see that SHRINK is now the fastest of the bunch. 

Bob mentioned that, "And the fact that CIS named Disk- 
Comm their official boot-disk standard tells me they have no 
problems with it either." I can't speak for what CIS does or 
doesn't do, nor can I really speak for what GEnie does or 
doesn't do. I have no contact with CIS at all. On GEnie, as 
I have said all along, whatever the RoundTable members 
want is what I will do. However, in the recent online survey 
on GEnie, it was shown that the members had the following 
preferences: 



ARC 


53% 


Scrunch 


2% 


Shrink 


2% 


Diskcomm 


7% 


SCOPY 


1% 


Other 


1% 


None 


8% 


No pref. 


25% 



While this only reflects the attitudes of the GEnie users 
that took the survey, it's all we have. 

As I said in my prior article, we do need something bet- 
ter than anything that's out there now. I just wish that I had 
the skill to write it! 



View of File Compaction Systems —A Rebuttal 
by Jeff Kyle 



First off, I'd like to thank Marty Albert for promptly redo- 
ing the compactors comparison, and taking a second look at 
Disk-Comm. However, I couldn't believe you liked 



SHRINK XE so much, so I decided to load the old sucker 
up and test it against Disk-Comm. 



First: you should note that neither SHRINK nor 
SCRUNCH can handle double density disks. This is a 
serious problem. 

I went through and compacted and uncompacted the 
"Awesome #1 Demo" disk using Disk-Comm 3.2 and 
SHRINK XE 1.00. You say that SXE could compact the disk 
you used in 1:25. This is quite strange if you were using a nor- 
mal disk without UltraSpeed, which by the way DiskComm 
3.2 supports. 

So, here are the times I got. Note that this included all the 
reading/writing time, and the compacted disk was in a DD 



RAMdisk. Therefore the "size" will be in double density. To 
find the single density size, just multiply by two. Also, the 
input and output disks were in UltraSpeed, speeding up 
reading/writing by approximately 3X. 

Program Time In Time Out Size 
Shrink XE 1:57.5 0:48 176 

DiskComm 0:58 0:52 152 

Obviously Disk-Comm is faster, and creates smaller files. 
This, plus all the extra features, support of SD/ dual/DD, 
plus "non-conforming" drives, should make Disk-Comm the 
clear winner. 



Why I Hate Compaction All Together! 

by Dominick Palance 



Now I'm no great programmer and I don't know assemb- 
ly and I'm not totally perfect at BASIC, but I'm an Atari user 
non-the-less. I feel its time for another totally different out- 
look on compaction. 

I started telecommunicating this past summer with my 
Atari XM301 and now use a SX212. That was the first time 
I saw ARC. I didn't know what it was at first, but now we all 
know that it is a program that makes files smaller and links 
them back. It saves downloading time and takes up less disk 
space to store on a BBS. 

BUT, you must UnARC the file to run. No problem, but 
it does take time. But better to spend the time off-line so not 
to run up a bill. I kind-of liked the idea at first and a lot of 
files are ARCed, so I got an unARCing program. At 300 
baud a smaller file is great and is OK even at 1200 baud. 

"But where's the part about why I hate it?" you say. Well, 
hold on. 

I've seen many ARCed files and they've always run (well, 
99% of the time) and I needed therefore to have an unARC 
program as I said. Then, I started seeing "other" compac- 
tors and some files used them, but not nearly as many that 
used ARC. Some are SHRINK XE, Disk-Comm, and 
SCRUNCH. This kind of put a dent in things. I didn't want 
to spend my time downloading all these compactors/uncom- 
pactors, let alone go to the trouble of separating files into 
groups by which compactor they used. 

One compactor was fine for me, two tops if really needed. 
The second most popular I've seen is SCRUNCH. To make 
things worse, there seems to be more and more compactors 
coming out these days. I happen to like ARC because there 
are so many files using it and its so easy to use. SCRUNCH 
is faster, but doesn't seem to do as much compacting, so why 
use it? What's the point? Plus, its not user-friendly and it to- 



tally wiped out one of my double density SpartaDOS disks. 
I've only gotten SCRUNCH to work with DOS 2.x. As for 
the others, I hardly see any files using them, so why not for- 
get them? 

As for ARC, it will support my SpartaDOS disks and does 
a lot of compacting. I don't mind the wait then. But still, I 
don't like going to the trouble of going through the process. 
You have to do download the entire file that may contain 
files you already have and you have to unARC them all. Plus, 
some files are called AUTORUN.S YS as if they are gonna 
be the only file on the disk. That's not too bad. But when 
ARC ruins the file by adding a byte here and there (or so I 
hear) then that's not good. 

Sometimes, compaction is totally uncalled for and still its 
used and I have to go through a long, slow and hard process. 
And with 2400 baud coming, you may not notice the time 
saved compared to a file not compacted. On larger systems 
with more memory, okay, maybe compaction could help, but 
as for us 6502 users, not always. 

I downloaded a package of AMS files with a TV theme. I 
believe it was ARCed. When I looked at all the files 
separated, I already had half of the files included! BIG 
waste! 

On one system I call, you can upload a group of files re- 
lated in some way and put them all under one title in the 
directory. That way, you can either download the file, 
documentation, or the source code, or 3II of the files. This 
only leaves a need for compaction to make the files and time 
to download smaller, but it does not always matter. Do I 
make sense or are you asleep already? 

I welcome any comments on this; thank you for your at- 
tention. 



A Different Look At ARC 

by Jeff Kyle 



OK. So you like ARC, eh? So you like saving time 
downloading, eh? So you like being able to get all the files 
in one nice package, eh? Think again. ARC is one of the 
programs that shallgo into legend, but shouldn't go in a posi- 
tive way. 



Believe it or not, that innocent program isn't so innocent. 
A program this potentially dangerous should never be 
released, much less into the public domain. (No, I'm not 
saying sell ARC.) You've probably noticed one of ARCs big 
problems in that it barely works with any DOSs. ARC will 
refuse to work in most DOSs, and when it does work, it acts 



differently in most. In some, it will print out more than in 
others, in some (MyDOS) it will somehow manage to lose 
characters in the directory. It's not easy to code something 
to work that bad. 

And once you get it working, be prepared to be bored out 
of your skull. Just enter the name, and WAIT. You can't get 
a directory, it doesn't like problems, and once you've final- 
ly got that darn file ARCed, that's it. You can't manipulate 
what's in it as you can in ARC files on other machines. If 
you've closed the ARC, that's it, you can't change it. If you 
do want to change it, you have to start all over. If you get a 
huge ARCed file, but only want one file out of the middle, 
tough luck. You've got to wait and wait for it to slowly 
process all the other files that you don't need. But so far I've 
just mentioned "extras". 

Now for the bad part— yep, it's true, ARC does murder 
files. You've all seen the messages that say "you'll get CRC 
errors on this that and the other, but don't worry, they're 
fine". Well, they're nol fine, they are damaged, and some 
files that don't get CRC errors are damaged also. Each time 
a file fails the CRC check, it's been damaged in some way. 
Pictures can have stray bytes in them, text files may get stray 
letters, binary files malfunction slightly. Anyone who's seen 
the ARCed "Digital Nosebleed/Atari Wave" knows that 
ARC can easily do major damage to files. When a local per- 
son cleared out the bad bytes and reARCed the clean ver- 
sion of the program, it had the same problems. 



ARC tries to justify this by saying that it is removing 
"XModem block padding". This just doesn't make sense. 
The only time it ought to have this is at the end of files, but 
ARC happily changes bytes right in the middle of files. And 
why is it I've seen much more of the "XModem padding" at 
the ends of text files that have been ARCed than haven't 
been? 

And of course this can cause many problems. Occasional- 
ly a machine language program may refuse to function. 
Demo programs may be almost unusable, as in Digital 
Nosebleed. And what if you have an important text file, full 
of specific data? It would be easy for ARC to change one of 
those and very much mess up the file. 

So what are the alternatives? If you need to compact one 
file, use SQUISH. It is faster, and has about equal rile com- 
paction, and is easily modifiable to turn the screen off while 
working by anyone with a rudimentary knowledge of Ac- 
tion!. If you have to put many files together, Library will ac- 
complish that quite nicely. If you have to do many things and 
want them all together along with a DOS, etc, Disk-Comm 
will do compaction and put the whole disk together as a nice 
neat file that tells you if you have bad bytes in a file. 

So think about this next time you decide to use ARC. 
There are alternatives. Nothing is as good as it could be, but 
yes, that is being worked on. (Hint, hint!) So, go on. Go for 
it. Stop using ARC. Your programs will thank you for it. 

If you'd like to further discuss this matter, feel free to 
leave me E-Mail on GEnie for JEFF-KYLE. 



SpartaDOS FOR BEGINNERS -part II 

by Ed Bachman 



Well hello again. As you recall in the last segment we were 
working our way through the Atari DOS 2.5 menu. We just 
finished discussing menu option I so this segment we'll start 
with section J. But first I'd like to digress for a moment. 

In the interest of the beginning SpartaDOS user, I'm only 
dealing with the Atari similar commands. This is to get you 
up andrunning. As to the SpartaDOS commands which have 
no Atari equivalent, well, once again I recommend the 
SpartaDOS Tutorials (watch for them in future issues of Fuji 
Facts— Ed.), and perhaps an article with a beginners' look 
at the non- Atari commands will be out in the mture. 

__ J -DUPLICATE DISK 

This is a difficult one, simply because there are two Spar- 
ta commands that come under this type of operation. The 
first, "SCOPY" is the most similar of the two SpartaDOS 
commands. However it is also the most difficult to explain. 
The second SpartaDOS command is "DUPDSK", a utility to 
duplicate the contents of a source disk to an already for- 
matted destination disk. This is a good utility for making 
multiple copies of the same disk. I plan on detailing both of 
the SpartaDOS commands, but first I want to review just 
what the Atari DUPLICATE DISK is all about. 

DUPLICATE DISK is a disk copy routine that produces 
an exact copy of the source diskJn addition, DUPLICATE 
DISK will also check to see if the destination is formatted 
and if not, will format it for you. 



SpartaDOS equiv. = DUPDSK 

DUPDSK is another External SpartaDOS command 
which means you must have a copy of this file in the default 
drive (note: we covered the default drive, in part 1 of this 
series). DUPDSK will simply copy the contents of a source 
disk to an already formatted destination disk. One caution 
here, DUPDSK does not format the destination disk, and 
the density of the disk and number of tracks must match. The 
destination disk does not have to have DOS written on it 
however, because if the source disk has a bootable version 
of DOS on it, it will be duplicated here by DUPDSK. 

Note that the utility DUPDSK will then ask for source 
and destination drives and prompt you when, if necessary, 
to swap disks. 

SCOPY in it's simplest form is muck like the Atari Dupli- 
cate disk. In that it will format the destination disk. SCOPY 
will also copy between different densities and sector skews 
(normal or hi-speed). And Scopy will also copy to or from a 
RAMDisk. But SCOPY must be told this in its command 
line. Confusing, eh? 

Note: a single drive SCOPY can be slow if you have a full 
disk. One way around this is to format your disks with DOS 
and use the Sparta XCOPY command as it seems to reserve 
a bigger buffer in memory than SCOPY. XCOPY has no 
Atari equivalent, but I'll go into detail later, when we get 
down to duplicate file. 



Now, above you've seen the simple SCOPY commands 
but what if we have a disk in hi-speed sector skew? The hi- 
speed I/O is part of what we got this DOS for in the first 
place right? Well, SCOPY needs to know this when you issue 
the Scopy command. Here's a simple two drive SCOPY with 
both disks in hi-speed format. 
D1:SCOPYD1:/U D2: /U 

Note th "slash-U". The U stands for "ultraspeed", the 
slash just appends it to the filespec. Also note the spaces be- 
tween scopy and Dl:, Dl: and fU and particularly between 
Uand D2:. 

You can also Scopy to or from a ramdisk as shown below. 
D1:SCOPYD1: D2:/R 

Note the /R stands for ramdisk and needs to passed along 
in the in initial SCOPY command. Since SCOPY formats 
the destination disk, I don't recommend using any of these 
RAMDisk examples unless your RAMDisk is larger than 
180K in size. 

K-BINARYSAVE 



The Atari binary save is similar to the Sparta SAVE com- 
mand. Note that the binary SAVE differs from the SAVE 
command in BASIC in that you must be in DOS to issue a 
binary save command. The file is saved in a similar manner 
to Atari DOS, with an $FF $FF header followed by the start 
and end addresses. Even the syntax is the same as Atari, ex- 
cept that you are not asked for an "Init run" vector to create 
an Atari DOS compatible "load and go" file. You must use 
the PUTRUN command, which simply appends the run vec- 
tor to the end of the file. 

Before we move on, remember that the start and end ad- 
dresses are in hexadecimal, not decimal notation! 

L — BINARY LOAD 



This is just as similar to Sparta as the binary save. The 
main difference between this command and the Atari ver- 
sion is that in Atari you must type "/N" to load the file 
without using the init/run vectors. Sparta on the other hand 
ignores the init/run vectors and just loads the file into it's 
specified block of memory. How do we get them to run is 
the next order of business. 

M-RUN AT ADDRESS 



Give this a hexadecimal address of the binary file loaded 
into memory and it will run it. There are two ways to run a 
machine language program in SpartaDos, and both are pret- 
ty slick. 

There two ways to use the RUN command. The first, with 
a run vector, the second by just using the RUN command. 
Suppose you've just got through usmg XINIT you've for- 
matted three disks, you've exited to DOS and you realize, 



hey! I need two more disks formatted! So instead of reload- 
ing XINIT you simply type RUN and XINIT comes up run- 
ning! So when RUN is used without a run vector it will run 
the last machine language program executed, providing it 
hasn't been overwritten by another memory destructive 
command like another object file. And when RUN is used 
with a run vector the file loaded into memory with the Spar- 
ta load command will execute. 

Now, for the second way to RUN AT ADDRESS in 
SpartaDOS. If the file is a binary file and has init/run vec- 
tors then you can simply type in the name of the file after the 
prompt hit return and it will execute! Better still if the file 
name extender is COM then it is only necessary to type in 
the first name of the file, this is how the Sparta external com- 
mands (XINIT, SCOPY,etc) work. 

N - CREATE MEM.SAV 



One of the true joys of Atari DOS (I hope you understand 
I mean that sarcastically). Part of why it's so slow. There is 
no MEM.SAV command in SpartaDOS as Sparta is a 
memory resident DOS, and many of its commands are inter- 
nal. You can exit to DOS and your program will be left in- 
tact. However there am memory destructive DOS 
commands, so it's a good idea to save your work if you plan 
to do any copying, or executing any external commands,or 
binary loads from DOS. 

O- DUPLICATE FILE 



Here again, there is no SpartaDOS command like this. 
However, there is a fine file copying utility called XCOPY. 
This a menu driven file utility that aUows you to tag or untag 
files to copy. It lets you read and write to the main menu on 
a disk, but you can specify a read or write or both from a sub- 
directory. Note that the subdirectory titles are not shown as 
part of the disk directory. You must specify a subdirectory 
to read from/or write to. It also lets you configure any drive 
as a source or destination. 

P- FORMAT SINGLE 



I don't know why anyone but an 810 owner would want to 
do this. XINIT will take care of this you can use AINIT, an 
internal command unless you happen to be using BASIC XE 
or a parallel device of some sort then this command and the 
enghsh error messages are disabled. 

Well, that's it for this segment. I hope I've enlightened 
some of you on the workings of SpartaDOS, even though I 
know it could have been more detailed. The copy commands 
alone could occupy a whole article. I'd enjoy hearing from 
anyone who has read these articles and has any comments „ 
or suggestions. If there is enough interest, there might be 
another article on the non- Atari SpartaDOS commands. So, 
happy computing, and in the words of Mark Bray, 
SpartaDOS rules! 



ST Emulator for the Eight-Bits! 
reprinted from Michigan Atari Magazine, January 1988 

byD.F.Neff 



Last year the Atari community waited while Atari Cor- 
poration fought to prevent the release of the eight-bit 



emulator for the ST. This show of resistance may have been 
just a smokescreen to hide a secret research project from 



the users' groups! If we look back at what was occurring, and 
read between the lines, all the evidence points to the same 
conclusion: Atari is developing an ST emulator for the eight- 
bits! 

The Clues 



First, Atari began selling stock to the public. Jack Tramiel 
said he was doing this to get money to pay some bills. Now, 
Jack has lots more money than you or I have and we don't 
need to sell stock to pay our bills. But Jack is a nice guy so 
we didn't ask what he planned to do with the money. 

Second, Atari repeatedly says that they are going to con- 
tinue to support the eight-bit machines. I've never heard 
them say they're going to continue to support the sixteen-bit 
machines though! That sure looks ominous for the ST's fu- 
ture. 

Third, after a weak fight to prevent the release of the 
eight-bit emulator, Atari allowed it to be released to a dis- 
appointed public. The emulator was a mere shadow of its 
prerelease image. 

Was Atari's resistance to the emulator's release just a 
smokescreen to divert attention from the expensive research 
being done on the ST-emulator? 

The Motive 



When Jack Tramiel bought Atari from Warner, he 
received thousands of brand new eight-bit machines, al- 
ready built, just sitting in the warehouse. Now, consider that 
when Atari sells you an ST, they have to build it, and that 
costs money. But if they had an ST-emulator on disk, they 
could just give you an eight-bit machine with the emulator 
disk, for the price of an ST. Since they already have the 
machine, the only cost to Atari is the $0.23 for the disk! The 
term "gross profit" takes on a whole new meaning in this 
scenario. 

Proof 



When the eight-bit emulator was demonstrated, Atari 
quickly pointed out that the eight-bit software was running 
at half-speed, at best. It was another smoke screen to prevent 
us from realizing the obvious: the ST can run only half as fast 
as an eight-bit! 



It's logical that any sixteen-bit machine will run more 
slowly than an eight-bit machine. Let me use the analogy of 
human speech to demonstrate that. If I start throwing 16-let- 
ter words at you, our conversation will proceed very slowly 
while you try to figure out what I am saying. In fact, you'd 
probably have to keep referring to a dictionary to figure out 
the 16-letter words I'm using. Big words just slow things 
down. 

However, if I talk to you in 8-letter words, our conversa- 
tion will take place much faster and end more quickly. 
Likewise, if I talked to you in 4-letter words, you'd end the 
conversation very quickly! It's no wonder the eight-bit 
machines can run faster than the sixteen-bit ST. 

At this point, ST owners are probably thinking that the 
ST files are too large to fit into the normal eight-bit memory. 
Well, most of the room used by an ST file is for the Diction- 
ary. That's right, the ST doesn't understand those sixteen- 
bit words and has to look them up in the dictionary. Once 
you've stripped the dictionary from an ST file, it'll probably 
fit into an unmodified 400! 

A public domain vaporware program called TICA (Ton- 
gue In Cheek Algorithm) translates each sixteen-bit word 
mto two eight-bit words. All timing loops are lengthened 
during the conversion by TICA, since the ST program will 
be running twice as fast on the eight-bit machine. 

ST graphics conversions are a problem. Users of the 
eight-bit machines can choose from a field of graphics 
screens which range from Graphics 0 to Graphics 32. ST 
users can choose only High, Medium or Low (like on a cheap 
clothes dryer). TICA changes all ST graphics to eight-bit 
Graphics 0 so you can see the individual pixels. That 
eliminates one of the most annoying shortcomings of ST 
graphics — all the pictures look like photographs. Who's 
going to believe you created that picture on your computer 
if they can't see the pixels? 

Conclusions 



It all adds up to the same thing— Atari is coming out with 
an ST emulator for the eight-bit machines, and will stop 
production of the ST line. Still have doubts? Consider this 
then: why does Antic, the magazine respected and lover by 
users' groups and SysOps nationwide publish their ST 
programs on an eight-bit disk? 



The NewsRoom 

reviewed by Bill Pike 



Springboard Software has ported The NewsRoom to the 
eight-bit Atari machines. The program requires 64K of 
memory (800XL, 65XE, or 130XE computers), a 1050 or en- 
hanced density-compatible disk drive and a printer; a joys- 
tick is optional. By tne way you must load the program with 
BASIC enabled (keepa you fingers off the OPTION key!). 

This is a program that has proven very popular on the 
Apple and Commodore machines. The program is the first 
desKtop publishing system released by a major manufac- 
turer for the Atari 8-bit machine (As a user of XLent 
Software's Typesetter for over a year, I disagree.— Ed). The 
cost is $39.95 and it comes in a plastic box containing the 



program disks, documentation for the program, advertising 
for other Springboard products and the warranty card. 
There is an unlimited lifetime warranty on the software for 
a $5.00 charge and proof of purchase. 

Now, "the facts Ma'am, just the facts". Newsroom ap- 
pears to be aimed at the 7-13 year old market. There are 
several sections to the Newsroom (the Banner, the Photo 
Lab, the Copy Desk, the Layout, and the Press). Newsroom 
uses a series of 8 plates to construct a 8 1/2" X H"oage (two 
across and four down) or you can have a Banner (headline) 
and 6 plates (banner 4- two across and three down). You 



can also print on a legal size sheet with 10 plates. Each plate 
is a single graphics 8 screen. 

The clip art disk contains rather "cutesy" line drawings 
of various aliens, space ships, dogs, cats, birds, and people. 
There are several maps of various continents some with 
countries shown. You can take rectangular sections out of 
any of the clip art files, and position the artwork anywhere 
on the plate you are working on. You can erase, re-draw, or 
fill any of these pieces. There is even a magnification option 
for fine work. However, once you modify the clip art, in any 
way, you cannot save it back to a clip art disk; you have to 
save it as a photo. You can create your own clip art, but you 
are not allowed to maneuver the art around or crop it or 
change it. Once you start to work with the clip art you must 
save it as a photo, you can not save it back to the clip art disk. 

There are 5 fonts that you are able to print with: small 
serif, small sans serif, large serif, large sans serif, and large 
english. The cursor is sized to fit one letter, which is nice for 
text placement. However, those are all the fonts you get and 
you can't get any more. The program will fit text around an 
icon or artwork automatically; however you must type in 
each letter, you cannot use a text file. This means there is 
nothing more than simple text editing available. You are un- 
able to use a separate word processor or spelling checker. 

The printed output of the program looks acceptable but 
not exceptional. However, you can fill in shading on the ban- 
ner and/or clip art for a better look. 



The amount of warnings regarding copyright are really 
something to see. On the front page of the manual you are 
told that these disks are copy-protected and that trying to 
copy them can destroy the program and/or your equipment ! 
You are told to send your warranty card, the backup copy 
order card, your proof of purchase (you are told to make a 
copy of the sales slip for your files) and include $12 for a 
backup copy. In the back of the book you are told that you 
can make one copy of the program for backup purposes but 
you may only use the program on one computer at a time 
and that you may not sell the program without the consent 
of Springboard Publishing. In other words you bought it, 
you're stuck with it! You are also told that you have pur- 
chased the media, disks and documentation, but 
Springboard retains all rights to the program or any part 
thereof. However you are allowed to make unlimited copies 
of the newsletter output. 

All in all, the program appears to be designed for the 
elementary classroom. The commands are, for the most 
part, icon driven and are relatively easy to use. If you wish 
to pay $40 to allow your kids to put together a newsletter, 
this looks like your best bet. But if you are doing serious desk 
top publishing on a adult level I would recommend News 
Station and News Station Companion by Reeve Software or 
Daisy Dot from Roy Goldman {available in the ACEC Disk 
Library— Ed). They do much more for a lot less money. 



Terminal Software Comparison 

by J. McCormick 



Amodem, DeTerm, Express. All very good terminal 
programs, all share-ware. But which one is the best? This is 
my comparison of all three of these terminal programs, 
showing you the strong and weak points of each. 

Amodem is the terminal program written by Trent Dud- 
ley. Amodem was one of the first terminal programs ever 
made for the Atari, and has been with us since the first bul- 
letin boards. Amodem is written in BASIC, using machine 
language code throughout the program. The version I tested 
was Amodem 7.5 

DeTerm was written by Jim Dillow. Because it's so new, 
this program is unknown for the most part, and it's main fea- 
ture is a game that you can play while transferring a file, re- 
dialing boards, or when you are online with a BBS! The 
version I used was the 1.00b, the beta test copy. 

Express! was written by Keith Ledbetter. This program 
is written in ACTION! and seems to be the favorite among 
most users because it's easy to use. The version I tested ver- 
sion 3.00. 

To show the major differences between these terminal 
program, he is a quick comparison chart: 
Feature Amodem Express DeTerm 



Key Buffer 
Xmodem 
CRC 
Ymodem 
Batch 



3 line 

Yes 
Yes 
Yes 



Yes 



2 line 

Yes 
Yes 
No 
No 



3 line 

Yes 
No 
No 
No 



Stick Input Yes No Yes 

Key Repeat Yes Yes No 

Word Wrap Yes Yes Yes 

Scrollng Yes 2 No No 

Game No No Yes 3 

Menus 27 38 37 

PCP 4 Good Little Excellent 
Smartmacro Yes No No 

BBS Macros 1 3 4 

Timer Yes Yes Yes 

Clock Yes Yes 5 No 

Bootup 6 1:07 1:05 1:10 

Length 176 254 198 

Buffer Size 7 4352 5504 7168 

Docs Excellent Excellent Average 

Send Time 8 2:00 1:58 2:23 

RcvdTime 8 2:06 1:53 2:23 

^Amodem has Ymodem batch RECEIVE 
gQn|y with- XE/XL models 

A game of Pong that can be played anytime on or offline \ 

Macro/Program support for P.C. Pursuit by Telenet 
g A real-time clock is available if you use SpartaDOS's TDLINE. 

Time needed to boot the terminal program using SpartaDOS 3.2 in 
double density with a simple STARTUP.BAT file 
gSize of capture buffer when using SpartaDOS 3.2 - ' [ > 

This is the time taken for the terminal program to receive and send 
an 85 block file at 1200 baud. The program was stored/sent from a . 
192K RAMDisk with SpartaDOS. The terminal did the transfer with a 
fast hard-drive BBS system. 



Amodem 



Amodem was the terminal I choose as being the best. It 
has features that the other terminals did not, Y-modem, 
Ymodem batch receive, smart macros, smooth scrolling for 
XE/XL computers, good documentation, a fast transfer 
time, and joystick input. The only real argument I had 
against Amodem was that you have only 1 macro containing 
your password for each BBS on your BBS list. That problem 
doesn't seem to big since you have 10 "smart" macros that 
are always there. 

DeTerm 



Determ was the clear loser in most areas. It's transfer rate 
was sluggish (1 block every 1.68 seconds at 1200), which was 
caused by a long delay in between each block. However, 
there are two features that make it an excellent terminal. 
Determ has full P.C. Pursuit support. It will re-dial cities 
until you reach one, and then it will load the city's phone list 
for you to dial with! The Breakout game was it's other big 
feature. The game does seem a bit buggy, but, it actually feels 
like multi- tasking without any pauses or jerky movement, no 
matter what you are doing! However, the documentation is 



only average, and I do not recommend this program for a 
beginner. 

Express 

Express had the fastest transfer rate of all of the terminals 
tested. Downloading at 1200 baud, it averaged one block 
every 1.33 seconds. It was also very user-friendly. My major 
complaint against Express is the macros, and the lack of 
Ymodem protocal. The macros are great, in that you may 
have three for each BBS. However, these are "dumb" 
macros. They will not react to input from the BBS. If you are 
using P.C. Pursuit, three little macros are not going to do 
much good. 

Some things I would like to see in all of these terminals 
are a Ymodem batch send, where you may mark files in your 
directory to send. Also, for those of us who don't really want 
to waste the time seeing what we are downloading, how 
about an option to turn the screen off and to use the extra 
speed for the transfer? 

That's the end of my comparison. If you do not agree with 
my results, or my conclusions, call up the Syndicate BBS and 
tell me your opinion! I'd be glad to hear it. 



A Review of the XF-551 From a Programmer's Point of View 
by Robert Puff 



Atari's new XF-551 disk drive certainly has been quite a 
suprise to many. I have seen many comments concerning it, 
and thought I would offer some of mine as well. 

The drive is just about the same size as the 1050, but not 
quite as high. It uses a generic-type double-sided direct drive 
mechanism which is nice and quiet, compared to some 
1050's I've heard. The drive uses the standard 9VAC power 
supplies used for the other 1050 and 810 drives. The back of 
the drive does get nice and hot, just like the 1050s, but that 
did not affect the drive's operation when I left it running for 
a month solid. 

The drive runs a little faster (300 rpm compared to the 
standard 288), but Atari adjusted for it by clocking the con- 
troller a little faster. So there is still the same amount of data 
in the same format on the disk. 

Now we get into compatability. Atari has done a fair job 
at making the drive compatible with the 810 and 1050, There 
is only one flaw I found; the missing-sector bit in the status 
bytes does not reflect a missing sector correctly. This should 
have been simple enough to do, but they did not. Because of 
this, there ARE protected disks that will not load on a XF- 
551. I do not have the titles with me at the moment, but any 
program that looks for a missing sector status will probably 
not work. 

The next subject is double density. Finally, Atari has 
come out with a true double density drive, which will read 
other double density disks. However, there are some 
problems here also. To determine the density of a disk, nor- 
mally you read sector 1, and then issue a status request. One 
of the status bytes will then tell you the density. This works 
fine for the XF-551 when it is in single or enhanced density, 
but not always for double. 



Instead, double density comes back with a status of en- 
hanced. Once you use the set density commands, the drive 
maybe set to double, and the status will be correct. Just don't 
go back into single, or you'll have to manually set the den- 
sity again. To summarize: if you use single and double den- 
sity disks, the drive will have a very hard time going into 
double. Since SpartaDOS has no way of forcing densities, 
this can be a real problem. The only way I've ever seen it do 
it automatically is when booting a double density disk (Note: 
I did figure out a way to make the drive reconfigure; it is used 
in Diskcomm 3.2). 

The drive is capable of double-sided operation, giving 
you a possible 360K storage when using double density. (Of 
course, you must use MyDOS or SpartaDOS because the 
DOS 2.5 it comes with supports none of this.) I found it 
strange that it will not use double-sided operation in single 
or enhanced density. 

Also another thing to think about is that it uses the index 
hole of your disks for timing. This means you cannot use 
those cheap hard-sectored disks anymore, and cannot write 
to the back side of the disk like you did with your 1050, 810, 
etc. Now this really dosen't matter if you use its double-sided 
capabilities, but if you want to make up a disk for your club 
or friend who has a 1050, and wish to use the back side, you 
are out of luck. 

The High-Speed disk I/O the drive boasts is very similar 
to Happy's 810 warp speed. Although not as fast as ICD's 
UltraSpeed, it is fast. The set-up is similar to UltraSpeed: 
you must format with a special sector skew for optimum 
speed, which will be slow when high-speed software is not 
used. Strangely enough, the drive only has a special sector 
skew for double density, even though the exact same com- 
mand is used for single density. I have been able to read 



single density disks formatted with UltraSpeed sector skew 
quite nicely on the XF-551. As of now, the only programs I 
am aware of that make use of the high-speed capabilities is 
my Disk Communicator program version 3.2. and THE 

ULTRASPEED + OS. 

Unfortunately, Atari did not make the drive for expan- 
sion. It uses an MCU chip that takes the place of many chips 



of the 1050 used. Because of this, and because it's not 6502 
based, I don't think you will see any products such as the 
Happy or Super Archiver available for a while. 

Well, I guess that's it. I have confirmed the bugs I found 
with later models, so it appears they haven't been fixed yet. 
Once Atari fixes these, it should be a very good drive at a 
nice price. 



June ACEC Meeting Minutes 

by Don Bowlin 



The June meeting was brought to order at 7:32 p.m. by 
Warren Lieuallen. After discussing the newsletter mailing 
schedule and other topics of general interest to the club, 
there was a demonstration by Don Bowlin of the Print Kit 
program from Hi-Tech Expressions. The demonstration of 
the Print Kit was followed by the raffling off of a similar 
program named Print Power, also from Hi-Tech Expres- 
sions. 

There was not actually a Disk of the Month for June. In- 
stead, the disk librarian offered for sale some the many un- 
cataloged disks that have been received over the years from 
various sources, such as other users' groups. These disks 
were offered at a discount from the normal $5.00 cost. 

The club's SysOp, Frank Seipel, was at the meeting to 
answer questions. Frank also passed out literature about the 
ACEC bulletin board and his own personal BBS, Pandora. 
There was a vote taken to establish a new "at-large" position 
to the board. Norman Knapp has expressed an interest in 
this position; there will be additional candidates solicited at 
the July club meeting followed by a vote of the membership. 
For those who might be interested in participating in a 



BASIC language course, Norman Knapp is trying to get a 
group together for this purpose. If you are interested, see 
Norm at the next meeting. Miscellaneous activities at the 
June meeting included the sale of some used equipment by 
one of the members. 

Since the club has its 520 ST computer again there were 
several requests for some ST demo's. As a result, it was 
decided at the last board meeting to review TimeWorks 
Publisher at the July club meeting. This is a desktop publish- 
ing program similar to Publishing Partner but newer and 
more powerful. Dave Feeney has volunteered to do the 
demo. Jim Murphy, our Disk Librarian, has indicated that 
he will be putting together an ST Disk of the Month at some 
future date. 

An item discussed at the June Officer's meeting was the 
possible raffling or auctioning off of the club's PowerType 
daisy- wheel printer at a future club meeting. The printer has 
not been used much as of late. For the July club meeting the 
board decided to raffle off the Print Kit program from Hi- 
Tech Expressions. 



July ACEC Meeting Minutes 
also by Don Bowlin! 



The July ACEC meeting was brought to order by Dave 
Beck. The treasurer reported that the club has had a loss of 
$248 for the last twelve months. This consisted of revenues 
of $2,238 and expenses of $2,486. There was no club newslet- 
ter in July, as explained in The Editor's Column. The July 
Disk Of the Month included several type-in programs from 
previous issues of Antic Magazine. The raffle prize this 
month was the Print Kit program from Hi-Tech Expres- 
sions. The winner was Paul Rogers. 

The July demonstration of Timeworks Publisher was - 
given by Dave Feeney. Norman Knapp was elected to the 
new at-large board position. Norm is trying to organize a 
BASIC language programming course. Anyone interested" 
m participating should contact Norm at the next meeting. 1 

Nominations for next year's officers will be accepted, at 
the August meeting. New officers will be elected in Septem- 
ber. The question o£ what to do with the club's PowerType : 
printer has been postponed until after the election. 

At the officers meeting it was decided to have an eight- ! 
bit versus ST demonstration of the F-15 Strike Eagle at the; 



August meeting. After the demonstration these two 
programs will be raffled off. Since there are not many ST 
owners in the club, the ST version should be easy to win! If 
there is time we will also take a look at The Newsroom 
program for the eight-bit. 

ACEC is a non-profit organization interested in ex- 
changing information about the Atari Home Computer 
Systems, and is not directly affiliated with Atari Cor- 
poration. 

^Atari" and the "Fuji" logo are registered trade- 
marks of Atari Corp. AU other trademarks copyrights 
an^|e^0;marks contained within this newsletter are 
registered to their respective owners. . - ; / 

The opinions expressed in this newsletter are solely 
thoke of the authors, and may not reflect the opinions 
of ACEC, its officers or members. Material contained , 
in Fuji Facts may be freely reprinted as long as credit is 
given to both Fuji Facts and the author, / fl 

Membership in ACEC is open to all for a $12.00 year- 
ly fee; Newsletters are available at our monthly meet- 
ings at DeSales High School, and are mailed to' 
members three times a year. 



Wanteds Dead or Aliye! 

Life goes on, as they say, and once again, "they" are right! Much to my delight, I am about to finish up by Ph.D. 
degree, and am moving on to greener pastures (I will be moving from Ohio to become Senior Scientist at Ortho 
Pharmaceuticals in Raritan, New Jersey!). While very exciting for me and my family, this also means that I will no 
longer be your humble newsletter editor. Luckily, there is a simple solution m sight. 

ACEC Elections! 

That's right, this is the golden opportunity you've been waiting for! Come on, with all the changes that Fuji Facts 
has been through in the last two years (remember back to when it was still "The ACEC Newsletter"?), I just know 
you've thought to yourself at one time or another "Geez, I could do a better job than this Lieuallen-schmuck!". 
Well, now's your chance to show us what you've got! 

In all honesty, preparing Fuji Facts every month does take some time, but can usually be done in a weekend (as 
long as you've been collecting and hoarding text files from other sources along the way). If anyone's interested, I've 
got the entire system set up on my 800XL (Until quite recently, I used PaperClip, The Print Shop and Typesetter 
exclusively; I've also got Daisy Dot II all worked out with TextPro.). 

In my opinion, there's no better way to keep current and informed about your Atari computer — the editor 
receives newsletters from other clubs all across the country, and is usually on of the first to hear all the most recent 
news and rumors (free review copies of new software are also not unheard of!). 

So go ahead and give it a try; you've got nothing to lose but your newsletter! 
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